【脆弱性対応】AWS Systems Manager Patch Manager を使ったパッチ戦略の例
AWS Systems Manager(SSM) Patch Manager を使ってパッチ適用を自動化できます。
本ブログでは Patch Manager で実現できるパッチ戦略の例をいくつか紹介します。 Patch Manager でできることをざっくりと理解してもらえると幸いです。
※そもそも Patch Manager って何？深堀りしたい方は以下ブログを是非御覧ください。
- 【AWS Systems Manager】パッチマネージャー実行時の関連リソースを、絵で見て（完全に）理解する。 | DevelopersIO
- 【AWS Systems Manager】パッチマネージャーの パッチベースライン と パッチグループ の概念を勉強する | DevelopersIO
<<2021/06/24追記>> 実際の実装例を以下ブログにまとめています。
想定環境
以下想定するAWS環境です。
- 対象インスタンス群は Amazon Linux 2。すべて SSM管理下にある
- 検証環境、本番環境が存在する
例1. ほぼほぼデフォルト
参考として AWSが提供しているデフォルトベースライン AWS-AmazonLinux2DefaultPatchBaseline と、
それを使った(ほぼ)デフォルト設定のメンテナンスウィンドウを活用したパターンを紹介します。
- #対象
Patch Group=AL2タグが付いたインスタンスが対象です
- #実行タイミング
- 12:00 から 12時間毎にパッチ適用を行います
- #パッチ内容
- Security 系のパッチ(重要度 Critical, Important)で、リリース後 7日以上経っているものをインストールします
- Bugfix 系のパッチで、リリース後 7日以上経っているものをインストールします
とりあえず始められるメリットがあります。
しかし、パッチの例外登録などカスタマイズはできません。本番環境には安易に適用するべきではないです。
例2. 「パッチリリース後 N日」活用
#対象/実行タイミング
| 検証環境 | 本番環境 | |
|---|---|---|
| 対象 | Patch Group=AL2-STG | Patch Group=AL2-PRD |
| 実行タイミング | 毎日 AM 2:00 -- AM 3:00 | 毎日 AM 2:00 -- AM 3:00 |
#パッチ内容(承認ルール)
| 分類 | 重要度 | 自動承認(検証環境) | 自動承認(本番環境) |
|---|---|---|---|
| Security | Critical, Important | パッチリリース後 1日 | パッチリリース後 31日 |
| Bugfix | - | パッチリリース後 1日 | パッチリリース後 31日 |
#パッチ内容(パッチの例外)
| 検証環境 | 本番環境 | |
|---|---|---|
| 承認済みパッチ | 無し | 無し |
| 拒否されたパッチ | 無し | 検証環境パッチで問題が出たもの |
パッチグループごとに異なるベースラインを指定します。
検証環境と本番環境でパッチインストールのタイミングをずらすことによって、 パッチインストールの影響を事前に検証環境で把握できます。
継続的なパッチ当ての自動化を実現できますが、 検証環境で問題が出たときのフォローはしっかりとする必要があります。
例えば「 "検証環境パッチで問題が出たもの" は
一旦は本番環境の パッチの例外 に入れておく」フローを定めておきます。
例3. 「パッチ日付 YYYY-MM-DD」活用
#対象/実行タイミング
| 検証環境 | 本番環境 | |
|---|---|---|
| 対象 | Patch Group=AL2-STG | Patch Group=AL2-PRD |
| 実行タイミング | 毎日 AM 2:00 -- AM 3:00 | 毎日 AM 2:00 -- AM 3:00 |
#パッチ内容(承認ルール)
▼ Step1 (3月1日〜)
| 分類 | 重要度 | 自動承認(検証環境) | 自動承認(本番環境) |
|---|---|---|---|
| Security | Critical, Important | 20XX/03/01までのパッチ | 20XX/02/01までのパッチ |
| Bugfix | - | 20XX/03/01までのパッチ | 20XX/02/01までのパッチ |
▼ Step2 (4月1日〜)
| 分類 | 重要度 | 自動承認(検証環境) | 自動承認(本番環境) |
|---|---|---|---|
| Security | Critical, Important | 20XX/04/01までのパッチ | 20XX/03/01までのパッチ |
| Bugfix | - | 20XX/04/01までのパッチ | 20XX/03/01までのパッチ |
例2. 「パッチリリース後 N日」活用 と同じく、
パッチインストールの影響を事前に検証環境で把握できます。
パッチ適用状況の足並みを揃えたい場合に活用できる設定です。
ほぼパッチ当てを自動化できます。 この例では月が変わるたび(Step1→Step2) に自動承認設定を変える必要がありますが、 そこまで負荷ではありません。Lambda など活用して自動化も可能だと思います。
※図には書いていませんが、
もちろん 例2と同じく「 "検証環境パッチで問題が出たもの" は
本番環境の パッチの例外 に入れておく」フローは必要です。
例4. 「承認済みパッチ」活用
#対象/実行タイミング
| 検証環境 | 本番環境 | |
|---|---|---|
| 対象 | Patch Group=AL2-STG | Patch Group=AL2-PRD |
| 実行タイミング | 毎日 AM 2:00 -- AM 3:00 | 毎日 AM 2:00 -- AM 3:00 |
#パッチ内容(パッチの例外)
▼ Step1
| 検証環境 | 本番環境 | |
|---|---|---|
| 承認済みパッチ | CVE-20XX-YYYYY | 無し |
| 拒否されたパッチ | 無し | 検証環境パッチで問題が出たもの |
▼ Step2
| 検証環境 | 本番環境 | |
|---|---|---|
| 承認済みパッチ | 無し | CVE-20XX-YYYYY |
| 拒否されたパッチ | 無し | 検証環境パッチで問題が出たもの |
この例では「承認ルール」は使っていません。 自動的にパッチをまとめてインストールすることはありません。
まず、 検証環境で 承認済みパッチ に入れたパッチがインストールされます(Step1)。
問題なければ 本番環境の 承認済みパッチ に同じものを入れてパッチを当てます(Step2)。
自動化のメリットは損なわれますが、脆弱性情報を1つづつ確認、慎重に対応を行いたい場合に有用です。
また、特定のパッチをとりあえず当てたいときにも使えます。(参考: Systems Manager Patch Manager で特定パッチを適用する | DevelopersIO)
おわりに
ざっくりと Patch Manager でできること把握できたでしょうか。 紹介した例をチューニング/組み合わせて、最適なベースラインへカスタマイズすると良いと思います。
今回は説明を省きましたが、ベースラインを定義するにあたって、他いくつかパラメータが あります。
- 再起動するかどうか
- セキュリティ以外の更新を含むかどうか
- など
実際に設定する際はこれらも考慮してカスタマイズしていきましょう。
参考
- AWS Documents
- DevelopersIO
